As should be appreciated, a virtual machine is a software construct or the like operating on a computing device or the like for the purpose of emulating a hardware system. Typically, although not necessarily, the virtual machine is an application or the like and is employed on the computing device to host a user application or the like while at the same time isolating such user application from such computing device or from other applications on such computing device. A different variation of a virtual machine may for example be written for each of a plurality of different computing devices so that any user application written for the virtual machine can be operated on any of the different computing devices. Thus, a different variation of the user application for each different computing device is not needed.
New architectures for computing devices and new software now allow a single computing device to instantiate and run a plurality of partitions, each of which can be employed to instantiate a virtual machine to in turn host an instance of an operating system upon which one or more applications may be instantiated. Typically, although not necessarily, the computing device includes a virtualization layer with a virtual machine monitor or the like that acts as an overseer application or ‘hypervisor’, where the virtualization layer oversees and/or otherwise manages supervisory aspects of each virtual machine, and acts as a possible link between each virtual machine and the world outside of such virtual machine.
Among other things, a particular virtual machine on a computing device may require access to a resource associated with the computing device. As may be appreciated, such resource may be any sort of resource that can be associated with a computing device. For example, the resource may be a storage device to store and retrieve data, and generally for any purpose that a storage device would be employed. Likewise, the resource may be any other asset such as a network, a printer, a scanner, a network drive, a virtual drive, a server, and the like. Accordingly, whatever the resource may be, the virtual machine may in fact be provided with access to services provided by such resource.
In a computing device with multiple partitions instantiated, any particular resource of the computing device may be dynamically assigned to a particular partition/virtual machine (hereinafter ‘virtual machine’ or ‘VM’) so that the particular VM can directly control such resource and service requests for the resource from other VMs on the computing device. Such particular VM, then, is in effect a host that provides resource capabilities as a resource host VM (‘VM-H’) that ‘owns’ the particular resource. Similarly, such VM-H provides resource services to another VM which is in effect a client that consumes such capabilities as a resource client VM (‘VM-C’). Thus, the VM-C and the VM-H in combination accomplish operations that require use of the particular resource.
A particular VM-C operating on a computing device typically is constructed to operate as if a real machine. That is, the particular VM-C in accessing a particular resource typically acts as if such particular resource is accessible by way of direct requests thereto. Accordingly, it may be the case that the VM-C has constructed a path or stack (hereinafter, ‘stack’) of drivers to which such requests are directed, with the expectation being that the particular resource is at the end of the stack. As has been established, however, the VM-C is not in fact a real machine and the particular resource is not in fact at the end of the stack.
Accordingly, it may be the case that the resource is emulated by the virtualization layer/virtual machine monitor as being at the end of the stack. In reality, the virtualization layer forwards a request for the resource to the VM-H that owns or has access to such resource. Similarly, it may be the case that the VM-C may be endowed with enlightened capabilities in which such VM-C is aware of the virtual existence thereof, and sends requests to the particular resource by way of an ‘enlightened’ stack at the end of which is a VM bus or other communications path that connects the VM-C with the VM-H that owns or has access to the resource, where the VM bus bypasses the virtualization layer. Also similarly, it may be the case that the VM-C with enlightened capabilities sends requests to the particular resource by way of a virtual pipe between the VM-C and the VM-H as implemented with the VM bus. Whatever communications protocol is employed, the VM-C accesses the particular resource by way of the VM-H, and accordingly each request sent by the VM-C to the particular resource follows a path to the particular resource by way of the corresponding VM-H.
Particularly with regard to the VM-H that owns the particular resource, then, it should be appreciated that such VM-H may directly access the resource by way of an appropriate adapter for the resource that is assigned to the VM-H. Typically, although not necessarily, the adapter is a piece of hardware or software on the computing device of the VM-H, where such hardware or software interfaces the resource to the VM-H. For example, such adapter may be a network interface card or a video card, or the software equivalent. With direct access to such adapter, then, the VM-H can employ the resource with a relatively high degree of efficiency and performance. Note here that a particular resource may have multiple corresponding adapters each potentially assigned to a particular VM-H, and accordingly multiple VM-Hs can own a particular resource. However, only one VM-H can be assigned to or ‘own’ a particular adapter at any one time, at least typically. At any rate, it can typically be assumed that ownership of a particular adapter is tantamount to ownership of the resource of the particular adapter.
One hallmark of a VM is that the VM as a virtual construct can be halted and re-started at will, and also that the VM upon being halted can be saved, retrieved, and re-started at will. In particular, the VM as instantiated on a particular computing device is a singular software construct that can be neatly packaged inasmuch as the software construct includes all data relating to such VM, including operating data and state information relating to the VM. As a result, a VM on a first computing device can be moved or ‘migrated’ to a second computing device by halting the VM at the first computing device, moving the halted VM to the second device, and re-starting the moved VM at the second computing device, or the like. More generally, a VM can be migrated from a first platform to a second platform in a similar manner, where the platforms represent different computing devices or different configurations of the same computing device. In the latter case, and as should be appreciated, a computing device may have a different configuration if, for example, additional memory is added, a processor is changed, an additional input device is provided, a selection device is removed, etc.
Note, though, that at times not all of the state information relating to a VM is included within the software construct of such VM. In particular, a VM-H that owns a resource or an adapter thereof may have particular state information relating to the resource stored with such resource or with such adapter thereof. As but one example, if a VM-H owns a resource which is a network and the corresponding adapter as owned by the VM-H is a network interface card, it may be the case that state information such as certain read and write commands for the network are stored in the network interface card, at least temporarily until acted upon. As another example, if the resource is an optical disk reading drive with an included adapter, it may likewise be the case that state information such as certain read commands for the drive are stored in such drive. As still another example, if the resource is a printer and the corresponding adapter includes a print spooler, it may also likewise be the case that state information such as certain write commands for the printer are stored in such spooler.
At any rate, it is to be understood that when a portion of the state information of a VM is not included within the software construct of the VM, such as may be the case when a VM-H owns a resource and stores state information with the resource, migrating the VM from a first platform to a second platform becomes more difficult. In particular, such migrating should not take place until the state information at the resource is dealt with such that such state information at the resource is not lost or otherwise permanently separated from the VM.
Thus, a need exists for dealing with state information of a VM-H at a resource owned thereby when the VM-H is to be migrated from a first platform to a second platform. In particular, a need exists for a method and mechanism by which the state information at the resource can be deleted from the resource in the ordinary operation thereof prior to the migration, or else can be stored for later retrieval by the VM-H after the migration, or else can be processed by another VM-H.